1. Field of the Invention
The present invention relates to a mechanism for setting resources for a data transmission between two network nodes, i.e. a user equipment and a base transceiver station. In particular, the present invention is related to a method and apparatus by means of which resources for a data transmission between a user equipment and a base transceiver station, such as an enhanced Node B (eNB) can be provided in case (additional) resources are required for the transmission, for example when insufficient resources are presently dedicated to the user equipment.
2. Related Prior Art
In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rd generation (3G) communication networks like the Universal Mobile Telecommunications System (UMTS), cellular 2nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolutions (EDGE), Long Term Evolution (LTE) or other wireless communication system, such as the Wireless Local Area Network (WLAN) or Worldwide Interoperability for Microwave Access (WiMax), took place all over the world. Various organizations, such as the 3rd Generation Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers), the WiMax Forum and the like are working on standards for telecommunication network and access environments.
Generally, for properly establishing and handling a communication connection between network elements such as a user equipment (UE) and another communication equipment or user equipment, a database, a server, etc., one or more intermediate network elements such as base transceiver stations, control network elements, support nodes, service nodes and interworking elements are involved.
The first “step” for establishing a communication connection is usually a connection between the UE and the base transceiver station representing the entry point to the communication network. There may be a plurality of UEs connected to one or more base transceiver stations. A base transceiver station is generally a fixed station, and may be, for example, an access point (AP), a base station (BS), an evolved NodeB (eNB) or the like. In the following, the base transceiver station is assumed to be an eNB implemented in an LTE environment.
Generally, a communication from the UE to the eNB is referred to as uplink communication (UL), and communication from the eNB to the UE is referred to as downlink communication (DL). The eNB may comprise radio frequency transmitter(s) and the receiver(s) used to communicate directly with the UE. Similarly, each UE may comprise radio frequency transmitter(s) and the receiver(s) used to communicate directly with the eNB.
For controlling a communication connection, it is necessary to exchange control information like control information bits in uplink and downlink directions. For example, a one bit scheduling request indicator (SRI) is transmitted in uplink, when UE has data to be transmitted in uplink. Furthermore, an indicator of downlink channel quality (CQI) is transmitted in the uplink to support UE scheduling in the downlink. Such uplink control information is transmitted, for example, by means of a so-called physical uplink control channel (PUCCH), as defined by 3GPP for evolved universal terrestrial radio access (EUTRA) or 3GPP LTE. PUCCH is designed to provide a high transmission reliability.
In addition to PUCCH, there is also defined a so-called physical uplink shared channel (PUSCH), which is used, for example, for transmission of uplink user data. PUSCH may be dynamically scheduled, i.e. time-frequency resources of PUSCH may be re-allocated for every sub-frame (wherein the UE is informed of the allocation of resources by using a so-called Physical Downlink Control Channel (PDCCH)), or resources of the PUSCH may be allocated semi-statically, i.e. semi-persistent scheduled. The idea of PUSCH is that any given time-frequency PUSCH resource may be used by any UE (e.g. depending on scheduling).
In the following, an uplink control channel, such as PUCCH, may be a frequency hopping resource located symmetrically in both edges of a system bandwidth. An uplink shared channel, such as PUSCH, may can be allocated in any place of the system bandwidth, possibly also overlapping with PUCCH. Hence, PUCCH and PUSCH may be different in such that frequency resources allocated for PUCCH are found at the two extreme edges of the uplink frequency spectrum while frequency resources used for PUSCH are in between. PUSCH is designed for transmission of user data, so that re-transmissions are possible. Furthermore, PUSCH is generally scheduled with less stand-alone sub-frame reliability than PUCCH. One reason for this is that physical layer re-transmission (such as a Hybrid Automatic Repeat reQuest) is supported in PUSCH.
There may be a situation where the UE has data in a buffer which are to be transmitted in the uplink direction but where no or insufficient transmission resources to the eNB are presently provided. In such a case, it becomes necessary to either request for additional resources to be granted by the communication control network element, i.e. the eNB, or to use commonly available resources for example on PUSCH which are not specifically dedicated. In both cases, there may occur either a delay in the transmission or the reliability of a correct transmission may decrease.
A mechanism which is related to such a situation is, for example, provided in by current LTE specifications, where as a feature of the LTE UL system a fast uplink scheduling request mechanism for an active mode UEs (i.e. being in the so-called RRC_CONNECTED (RRC: Radio Resource Control) state) is provided when the UE is synchronized by the eNB but has no valid UL grant on PUSCH available. In this case, the UE indicates the need for UL resources by means of the scheduling request indicator (SRI), for example.
In FIG. 7, an example of an existing resource requesting scheme is depicted. As can be seen in FIG. 7, the UE transmits, after having noted the need for additional resources due to the presence of data in a buffer and the missing of dedicated resources e.g. on PUSCH, a scheduling request indicator to the eNB (step M101). The eNB processes the request and searches for available resources in order to provide an asynchronous grant of additional resources available for the UE in uplink. After determining the corresponding resources, an uplink scheduling grant is sent (M102) to the requesting UE which is identified, for example, on the basis of the dedicated SR resource (on PUCCH) dedicated to the specific UE, for informing about the allocated resource. The UE detects the granted resources from this message and transmits in step M103 correspondingly the data to be transmitted in uplink, accompanied by an additional scheduling request, if required.
However, the procedure shown in FIG. 7 requires some time and causes thus a delay in the uplink transmission (compared to a case where the data could be transmitted immediately), i.e. a certain UL latency, due to the signaling taking place prior the actual data transmission. Furthermore, a signaling overhead is produced.
In order to reduce the UL latency, it is possible to consider different approaches to be implemented in the connection control. For example, the latency may be reduced by reducing the periodicity of scheduling requests. Another approach would be a pre-allocation of resources on the shared channel (PUSCH) to specific users which however reduces the flexibility and available bandwidth, and does also not represent a capacity optimized solution in particular in longer term scenarios. Alternatively, it may be contemplated to use a so-called contention based uplink transmission scheme where a plurality of UE has access to the same PUSCH resources, for example.
With regard to the latter approach based on a contention based (CB) transmission, this is achieved, for example, by allowing CB transmission only in uplink resource blocks that have not been reserved for a contention free uplink transmission. A dynamic assignment of uplink resources for CB transmission may be done by using PDCCH. Specifically, the eNB informs the UE that resources are generally, available, either by broadcast or dedicated signaling. The UE monitors on basis of the information from the eNB for available CB grants. After a CB grant for the resources is obtained, the UE transmits the data on contention-based PUSCH.
With the contention based (CB) transmission, it is possible to overcome specific problems caused by scheduling request (SR) procedures, in particular with regard to latency and signaling overhead. For example, SR may increase UL data transmission delay by several milliseconds, e.g. at least 5 ms, compared to a contention based transmission.
However, there may be other problems when using the CB transmission.
For example, in the case when a collision probability is high, e.g. when only few resources are available for the CB transmission or a high number of user equipments tries to use the CB transmission scheme, it is very difficult to predict a delay performance, and the delay performance as such may become bad. As an outcome, it is required to provide a high number of PUSCH resources for CB transmission so as to keep the collision probability low enough. This, however, reduces the number of available resources for other transmissions and may result in a higher overall processing load.
Furthermore, in case of the contention based transmission, the complexity of a receiver at the eNB side may be increased. This is caused, for example, by the requirement that the receiver has to be able to perform blind decoding for the CB resources as the sending source and the used coding scheme thereof can not be known, due to the nature of the shared channel principle. Thus, the receiver on the eNB side has to test possibly all used modulation and coding formats which requires increased receiver complexity.
Also performance issues have to be considered in case of CB transmission. For example, as a common resource is used, an identification of the sending UE has to be included in the signaling (i.e. inclusion of UE-ID in a MAC (Media Access Control) packet which has a specific size (e.g. up to 24 bits). This additional data reduces the UL coverage area.
Moreover, the CB transmission does not support specific error detection and correction methods, such as Hybrid Automatic Repeat Request (HARQ). Specifically, the CB transmission offers no support for ACKnowledgment (ACK) feedback, for example via a Physical Hybrid Automatic Repeat Request Indicator Channel (PHICH) since an ACK for a “hidden” UE causes higher layer errors. Moreover, in case when a transmission via PUSCH is failed, i.e. in case when PUSCH decoding fails, it is not possible to identify the sending UE, i.e. no capability to identify the goal for a NonACKnowledgment (NACK) is present. However, due to the lack of, for example, HARQ capability of the CB transmission scheme, a possible coverage area for contention based resource is limited. This will in turn impact to the delay performance as well.